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ABSTRACT 


This document provides the results of a study by OAOCO on the relation- 
ship of the NEEDS program to OSTA. The purpose of this phase of the 
study was to examine the NEEDS program and identify the interfaces be- 
tween OSTA and NEEDS and furthermore to assess the responsiveness of 
the NEEDS program to OSTA technological requirements. 

Section 2 includes a discussion of existing and planned NEEDS elements. 

Section 3 includes a definition of the relationship between NEEDS and 

future OSTA programs and includes an identification of potential bene- 
fits or impacts to OSTA through the implementation of NEEDS concepts/ 

elements. Section 4 identifies possible OSTA demonstration systems or 

pilots for the' NEEDS technology. 
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SECT-rON 1. INTRODUCTION 



SECTION 1. INTRODUCTION 


In order to meet the data processing requirements for NASA missions in 
the 1980 to 1989 time frame, the concept for a composite data manage- 
ment system known as the NASA End-to-End Data System (NEEDS) has been 
developed. By definition, NEEDS will be an ensemble of NASA data and 
information systems. Figure 1-1 depicts a functional diagram of the 
NEEDS. It is anticipated that the development of the NEEDS will pro- 
vice NASA with an organized, efficient data management and processing 
structure which can fulfill the data processing and dissemination re- 
quirements of future missions. 


This study will examine components of the NEEDS program. An "end-to- 


end data system" is defined as the total data system from the sensor 
to the end user. At the spacecraft a sensor makes observations (measure 
ments) which produce raw data. These data, or processed versions of 
them, flow through a sequence of processors/facilities used to trans- 
form, process and transmit them. The data is either stored in archival 
form and made available to users or ultimately reduced to information 
products which are disseminated to end users. The means of allowing 
for feedback of control information for management of earlier stages 
of the system is also considered part of the end-to-end data system. 


The NEEDS program has been structured into distinct phases to provide 
for comprehensive and unified planning, management review and approval 
of each phase, and a systematic and cost-effective technology transi- 
tion in the mid-1980's to new end-to-end systems. Each phase provides 
specific incremental gains toward overall improvement' in capability. 

The Phase 1 program focussed on the development and demonstration of 
five technology elements that would provide cost-effective solutions 
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Figure 1-1. NEEDS Functional Elements 














for several of NASA's very-near-term, high-data-rate processing problems, 
for software proliferation, and for the identification of data handling 
systems needed to satisfy future user requirements. These five techno- 
logy elements were: 

a. Synthetic Aperture Radar Data Processor 

b. Multi spectral Data Processor 

c. Digital Data Systems 

d. Multipurpose User Oriented Software Technology 

e. Resource Effective Data System Definition 

The specific objectives of NEEDS Phase 2 are: 

a. To provide the systems concepts, techniques, and technology 
which could increase the systems responsiveness: 

SQ-^lTat“ttie~ttlTrd"Betwe¥ff ~sWs ewrt “atfd pres elitT- 

tion of useful information to the user is reduced by two orders 
of magnitude where appropriate. 

(2) So that the time between a user obtaining information and 
the conditioning of a sensor for a new data collection is re- 
duced by two orders of magnitude where appropriate. 

(3) So that appropriate and timely reduction of data to infor- 
mation occurs as it progresses through the system. 

(4) So that the time required to exchange information (i.e., 
store, retrieve, and transmit) among users is reduced by two 
orders of magnitude. 

b. To provide the system concepts, techniques, and technology which 
could reduce the relative cost of extracting information from space 
data. 
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(1) Such that the unit cost of sensing an event and trans- 
mitting the useful data/ information to the user is reduced 
by an order of magnitude. 

(2) Such that the unit cost for extracting useful informa- 
tion from the data is reduced by an order of magnitude, and 

(3) Such that the unit cost for storage and retrieval of 
data/ information is reduced by an order of magnitude. 

c. To provide the systems concepts, techniques, and technology 
which could increase the degree of standardization throughout the 
system. 

(1) So that the increased efficiency of using industry stand- 
ard protocols, fo rmats , and subsystems throughout the entire 
system would be established. 

(2) So that increased efficiency would be demonstrated in the 
storage retrieval, and exchange of data, information, and know- 
ledge (e.g., as is required by the user in the macrocorrelation 
problems such as Weather and Climate and by some of the major 
elements such as the Space Transportation System). 

(3) So that concepts for the efficient use of complimentary 
ensembles of sensors used in space would be established. 

The broad objectives of Phase 2 are to continue to conduct systems analy- 
sis to guide and evaluate the program, to develop new technology and tech 
niques concepts, test and demonstrate at the brassboard level these new 
subsystems and demonstrate them in an integrated system configuration. 

The following is a partial list of developing concepts and technologies 
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relevant to the goals of the NEEDS Phase 2 and the overall NASA future 
space missions: 

a. VLSI Technology 

b. Fault Tolerant Computing Systems 

c. Fiber Optic Data Bus Integration 

d. Archival Mass Memory Technology 

e. Massively Parallel Processing 

f. Onboard Attitude Determination 

g. Improvements In Algorithmic Development 

(1) Radiometric Calibration 

(2) Geometric Correction 

h. Packetizing 

1. Packet Queuing ■ 

j. Data Capture, Data Staging Techniques 

k. Multi-Megabit Data Processing Architecture 

The major program elements of the NEEDS Phase 2 program are: 

a. Information Adaptive Systems (IAS) 

b. Massively Parallel Processor (MRP) 

c. Modular Data Transport Systems (MDTS) 

d. Data Base Management Systems (DBMS) 

e. Archival Mass Memory (AMM) 

f. Ancillary Data and Support Computing (ADSC) 

TJie relationship of these elements to the NASA data handling and data 
management system Is shown In figure 1-2. 

The long range goals of the NEEDS program are to Increase the data/ 
Information throughput of the NASA end-to-end data system by a factor 
of 1,000, reduce the system access time for space-acquired data by a 
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Figure 1-2. Relationship of NEEDS Elements to NASA Data Handling and 
Management System (Sheet ^ of 3) , 














Figure 1-2. Relationship of NEEDS Elements to NASA Data Handling and 
Management System (Sheet 2 of 3) 
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Figure 1-2. Relationship of NEEDS Elements to NASA Data Handling and 
Management System (Sheet 3 of 3) 








factor of 100, and reduce the support costs for the system by a factor 
of 10. Successful accomplishment of these goals is essential to NASA's 
ability to support missions planned for the future. 


SECTION 2. NEEDS PHASE 2 SURVEY 


SECTION 2. NEEDS PHASE 2 SURVEY 


2.1 SURVEY OVERVIEW/METHODOLQGY 

The Systems Analysis and Integration Team, part of NEEDS, is performing 
a continuing analysis and evaluation of the data/ information system in 
order to assess and monitor progress of the NEEDS program and isolate 
problem areas which need special attention from management, systems con 
siderations, or technology development. This activity provides the 
systems analysis and performance evaluation of the present system, sys- 
tems under development, or proposed end-to-end data/information systems 
The analysis will be used to guide the program toward the development 
of advanced techniques and technology solutions. Systems definition 
and integration and demonstration plans required between any of the 
other program elements will be provided by this element. These other 
program elements are: 

a. Information Adpative Systems (IAS) 

b. Massively Parallel Processor (MRP) 

c. Modular Data Transport Systems (MDTS) 

d. Data Base Management Systems (DBMS) 

e. Archival Mass Memory (AMM) 

f. Ancillary Data and Support Computing (ADSC) 

2.2 NEEDS ELEMENT EXAMINATION 

This subsection presents the results of the NEEDS element examination. 
For each of the elements the following four broad categories were used 
to assemble the data: 

a. Program Objective 

b. Technology Activities 


c. Element Interface 

d. Demonstration Activities 

Table 2-1 provides a brief look at the results. 

In the preparation of this section of the report on the existing and 
planned NEEDS elements the following criteria were used to guide the 
examination and assessment efforts: 

a. The objective and approach of this element.^ 

b. Relevant technology, requirements, existing candidate tech- 
nologies, trade-offs made and advancements needed. 

c. Available survey or comparison data, and other related NASA 

efforts underway. . . _ 

d. Conclusions reached and what future plans exist. 

^e.._In ter- element as so ciation. 

f. Capabilities demonstrated. 

g. Element status. 

Although all of these were applied to each area of study, some character- 
istics remain unknown due to the immature nature of some elements and 
lack of available documentation for others. The final draft of this re- 
port will incorporate any new information developed in the interim. 

2.2.1 INFORMATION ADAPTIVE SYSTEMS 

2. 2.1.1 Program Objective . The primary objective of this technology 
element is to develop and demonstrate onboard capability for data sets 
selection and adaptive processing of sensor data. Electronic and opti- 
cal processing components will be explored as candidate technologies 
for implementation of the concept. Figure 2-1 presents an IAS concept- 
ual view. 
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Table 2-1. NEEDS Element Status 
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2. 2. 1.2 Technology Activity . There are five major contributions which 
IAS can provide for NEEDS. These are: 

a. Data volume reduction. 

b. Timeliness in response. 

c. Adaptation to events which occur during sensing. 

d. Adaptation to the changing requirements of the user community. 

e. System modularity and standardization. 

These factors provide the basis for the following system requirements: 

a. Radi ometri cal ly and geometrically correct data to be generated 
by the sensor system. 

b. Onboard emphemeris determination and maintenance is to be 
achieved. 

c. The facilities of MDTS are to be utilized wherever possible. 

d. Data sets are to be selected through geographical region speci- 
fication. 

e. Autonomous algorithmic image processing is to be utilized to 
the greatest extent permitted by the state-of-the-art. 

f. There is to be a flexible user interface to the system 
via MDTS. 

g. There is to be onboard cloud detection and data deletion. 

h. There is to be onboard pixel classification at Levels I and II. 

i. The system will perform the signature tracking necessary to per- 
mit autonomous classification to take place. 

j. The system will provide for target identification and tracking 
between periods of observation. 

k. The system will provide an on-line long and short term data base 
Additionally, there are four long term IAS requirements: 

a. Adaptive resolution sensor. 

b. Efficient autonomous image processing algorithms. 
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c. Relational data base management system to support a base of 
10^^ bits. 

d. Dialect tolerant image processing language. 

A study v;as conducted by IBM of four architectural approaches capable 
of implementing the IAS functions. The approaches include; 

a. Custom Designed Computer 

b. Federation of Functional Processors (FFP) 

c. Distributed Microprocessor System 

d. Distributed Signal Processor System 

The last three approaches all represent a distributed architecture with 
the FFP having a high level of logic integration at the processor level. 
Much interest is currently focused on the last two distributed approaches 
due to a potential for lo wer overall system cost coupled with high sys- 
tem fault tolerance. 

The distributed signal processor system best suits the IAS high through- 
put requirements. Key to the design of any distributed architecture is 
the interconnection or busing structure and the available system functions 
among several processing elements. The Future Signal Processor (FSP) is 
representative of the system architecture best suited to IAS requirements. 

GSFC is studying various algorithms suitable for best demonstrating IAS 
concept development in radiometric calibration and geometric correction. 
Kentin and CSC contractors are working in support of the in-house soft- 
ware. 

Langley Research Center (LaRC) is studying hardware concepts needed for 
radiometric calibration and geometric correction. Texas Instruments, 

Inc. is studying charge coupled devices approaches to radiometric correc- 
tion. TRW is continuing to develop geometric correction software. 
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A breadboard table look-up approach to radiometric calibration was com- 
pleted and tested at 5 megasamples per second. Design goal is 15 mega- 
samples per second. 

Future actions include the following: 

a. A restructuring of 6SFC IAS efforts is underway. 

b. The IAS conceptual document will be completed. 

c. A contractor selection for the IAS demonstration will be made 
about November 1, 1980. 

d. A recommendation for extending IAS demonstration into FY83. 

e. Current goals are to design a brassboard hardware applying state 
of-the-art technology within a 2-year implementation period. 

Figure 2-2 presents an IAS spacecraft implementation block diagram. 

2.2. 1.3 Element Interface . The IAS developed technology will be inte- 
grated with that of MDTS, MPP, and DBMS. Because of slips in the MPP 
element schedule, the 128 x 128 version will not be available for an 
integrated demonstration. However, GSFC is proposing the use of an 
in-house developed 32 x 32 version. 

2. 2. 1.4 Demonstration Activities . An engineering model demonstration 
is planned for July 1982 (see figures 2-3 and 2-4) at LaRC. It will 
feature radiometric calibration and geometric correction concepts in- 
cluding data set selection and packetization functions. It will be a 
closed-loop data system in that test support and demonstration equip- 
ment will simulate both multispectral sensor output and output buffers 
interfacing. 

At the current time no significant technological advancements are ex- 
pected at the demonstrations, only technological concepts will be vali- 
dated. 


I 
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Figure 2-2. IAS Spacecraft Impliementation Block Diagram 
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Figure 2-3. Information Adaptive System Demonstration Configuration 














The demonstration will be a ground demonstration in a laboratory environ- 
ment. However, engineering model hardware will be used which will take 
flight requirements into consideration but will not be flight-qualified 
hardware. Although complete end-to-end data flow in real time with other 
NEEDS Phase II hardware elements will not be possible with this demonstra 
tion, the high data rate throughput and processing capability of the IAS 
will be demonstrated. 

The simulated sensor input will be a high-speed disk/high-speed semi- 
conductor RAM buffer, which can be loaded with data from Landsat tapes 
and/or special simulated data input. These data are then output to the 
other IAS hardware through the sensor electrical interface at high data 
rates consistent with planned multispectral sensors of the mid to late 
1980' s. 

2.2-.2— MASSIVEL-Y-PARALL-EL PROCESSOR • 

2. 2. 2.1 Program Objective . The objective of this program element is 
to build an image processing system known as the massively parallel pro- 
cessor that will perform logical operations at an effective rate of 

9 10 

10 operations/second with potential to 10 operations/second. 

These high speeds will be attained by simultaneously operating with 
16,384 modular computers that are arranged in a 128 x 128 array. As 
many as four modular computers will be fabricated on one silicon chip. 

Each processing element will contain a 1024 bit array memory. The MPP 
is expected to perform the following arithmetic operations: 

a. Six billion 8-bit additions and subtractions per second. 

b. Two billion 8-bit multiplications per second. 

c. 430 million 32-bit floating point adds/sec. 

d. 216 million 32-bit floating point multiplies/sec. 


2. 2. 2. 2 Technology Activity . For requirements, NASA has developed five 
algorithms which are used to provide an indication of machine types needed 
but which is technically feasible: They are: 

a. Cross correlation 

b. Extraction of maximum value 

c. Multispectral classification 

d. Nearest neighbor binary rotation 

e. Image resampling 

The only conmercial product competing in MPP technology is built by 
International Computers Ltd. (ICL); they have 32 x 32, 64 x 64, and 
claim to have a 128 x 128 capability soon. 

The GSFC/Goodyear MPP has two serious drawbacks: 

a. It cannot do serial problems. 

~~ b7 It dbeT not handle long word lengths well. 

Goodyear has researched the feasibility of applying the MPP to Synthetic 
Aperture Radar (SAR) digital processing (see subsection 2.3). 

Interim results of the Goodyear study on the MPP for SAR digital pro- 
cessing indicate that the MPP could easily become the most cost-effective 
solution for NASA SAR applications. 

Goodyear's effort indicate that: 

a. The MPP can service multiple sensors. 

b. The MPP is easy to reconfigure. 

c. The MPP/SAR implementation is well adapted to subsequent image 
processing including image enhancements techniques, target detection 
and classification. 

Table 2-2 illustrates via comparison the uniqueness of MPP technology. 
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•Table 2-2. MPP Comparison 
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A comprehensive study on array processors is available from Mitre 
Corporation (Document No. MTR-79W00305). This is the only NASA-sponsored 
study/development effort underway. 

The MPP is initially aimed at demonstrating a ground-based state-of-the- 
art image processing system. The ultimate effort from a NEEDS prospec- 
tive is its applicability to image processing aboard the S/C. This is 
expected by the late 1980' s. Studies have considered MPP use on Landsat-D 
but no current implementation plan exists. 

2. 2. 2. 3 Element Interface . The in-house (GSFC) 16 x 16 version will not 
be available for the IAS demonstration. 

2. 2.2.4 Demonstration Activities . A demonstration will be conducted by 
the contractor, Goodyear, in September 1982. The demonstration will 
address the requirements stated above. Figures 2 -5. 2- 6 . a nd 2-7 rep re- 
sent the various components of MPP technology. 

2.2.3 MODULAR DATA TRANSPORT SYSTEMS 

2. 2. 3.1 Program Objective . This program element will develop and demon- 
strate an integrated modular data transfer system which will provide on- 
board adaptive sensor sequence control, computational capability for 
onboard data handling, processing, and simplified, spacecraft data control 
and data transfer interactions for multipurpose, multi sensor experiments 
and payloads. The onboard data system utilizes a distributed micropro- 
cessor LSI architecture. The ground data transfer and processing portion 
of the data transport system will be developed, to take advantage of the 
special capabilities of the onboard portion of the system. 
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Figure 2-5. Basic MPP System Structure 
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Figure 2-6. Single MPP Processing Element 


2-16 




Figure 2-7. Basic Goodyear/NASA Design 
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2. 2.3.2 Technology Activity . At the time of this report, a concepts 
document was not available, however, some concepts supporting this 
element include: 

a. Instrument Telemetry Packet (ITP) 

b. Packet! zing 

c. Data Staging 

d. Packet Queuing 

e. Fault Tolerant Building Blocks 

The MDTS includes the following functional elements: 

a. A downlink consisting of: > 

(1) Command and Control /Data System (onboard) 

(2) Space- to-Ground Transport 

(3) Ground Transport 

(4) Data Staging (includes data accounting) 

b. Uplink consisting of: 

(1) Ground Transport 

(2) Ground-to-Space Transport 

Figure 2-8 shows MDTS functional elements. 

a. Instrument Telemetry Packet (ITP) . As a replacement for the 
conventional mtuliplexed telemetry frame approach, the ITP concept 
basically requires that the telemetry data from a single spaceborne 
instrument or spacecraft subsystem be temporarily assembled contain- 
ing only the data from’ a single instrument along with any required 
ancillary data (spacecraft clock, reference voltages, spacecraft 
and instrument control states, parity check bits, etc.) necessary 
for the validation, calibration, and cross-linking of this data 


2-18 



Figure 2-8. MOTS Functional Elements 











with other subsequently derived data sets (i.e., corrected time, 
position, and attitude). In the not too distant future it will 
be possible to generate and insert corrected time, position, and 
attitude directly into an IIP. Each IIP should be a stand-alone 
element containing all the data necessary for the validation, 
calibration, reduction, and interpretation of one or more experi- 
mental observations from a single instrument. Even a few years 
ago the IIP concept described herein would have been impractical 
due to the resulting complexity, cost, and power requirements. 

Now, with the emergence of powerful low-cost microprocessors and 
associated semiconductor memories, this concept is technologically 
feasible. 

The need for such a technique centers around the principle that the 
integrity of the observational data can best be ensured by encoding 
this data into a reliable transmission unit immediately at the 
source. Many of the problems and frustrations experienced within 
the telemetry data processing operations originate because the 
basic integrity of the sensor data is compromised before it reaches 
the processing site, thus necessitating complex andussually only 
partially successful recovery procedures. 

Three important advantages of the ITP concept; 

(1) A high-level source encoding function is provided to im- 
prove the integrity and autonomy of the resulting observational 
data. 

(2) For the first time it frees the instrument designers from 
the shackles imposed by a synchronous telemetry system. 

(3) The need to perform any mission and/or instrument-unique 
processing at any intermediary step within the overall process- 
ing cycle is eliminated. 
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Each of these features will have a profound effect on the overall 
mission data management. 

b. Packetizing . A packet telemetry system employing correction 
by retransmission control is believed to be a viable candidate for 
telemetry transmission from near-Earth satellites operating through 
the TORSS in the 1980's. 

A packetized telemetry system's unit of transmission of space ac- 
quired data to the ground would be a telemetry packet containing 
sensor data from only a single instrument along with the possible 
inclusion of the ancillary data (time, position, attitude, etc.) 
needed for the interpretation of this instrument data. This is 
in contrast to the conventional mode of telemetry operation in 
which sensor data from all instruments and spacecraft subsystems 

-are-word-mcrTttptexe'd~withtn-a-teTemetry-frame-formatT' and- subset 

quent ground processing is required to demultiplex this data into 
the individual data sets associated with each source. 

Some of the principal advantages of this system are: 

(1) Improved source encoding of instrument data. 

(2) Better bandwidth allocation on the basis of current instru- 
ment requirements. 

(3) Improved communications efficiency while virtually eliminat- 
ing all errors in the telemetry link. 

(4) Faster distribution of instrument data to the users. 

(5) A significant reduction in the ground processing and distri- 
bution costs relative to that required by a continuation of pre- 
sent methods. 
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While the system requires an increase in the onboard data system 
complexity, the system is well within the current state-of-the-art 
of digital system technology. 

c. Data Staging . Data staging in the NEEDS/MDTS concept is an 
identified grouping of functions all or some of which must be per- 
formed for/by each data user. Physical association of these func- 
tions is not a requirement; that is, data staging may be centralized, 
distributed, mission unique, or -some eomb'i nation of these options. 

Data staging is the interface between the data acquisition network 
and the user (or main data base) distribution network. As such it 
provides user data selection and rate smoothing (so that user links 
do not have to be sized to the peak transmission rate of the space- 
craft), and communications protocol conversion between the two net- 
works. 

Data staging includes a data capture function which provides a short 
term (nominally 48 hours) data base to provide a major point of pro- 
tection against data loss (the first point, in the TDRSS mode) and 
to support the other data staging functions of data preparation (tape 
recorder data reversal, redundant data deletion and data cataloging), 
product generation and system accounting. 

A ground-based data staging effort to support the MDTS demonstration 
(see below) is being developed at GSFC under B. Jones. 

d. Packet Queuing . The concept of adaptive packet queuing with 
bandwidth selection is being examined with the JPL activities men- 
tioned below. 

e. Fault Tolerant Building Block . The primary constraints on the 
onboard computing system are the requirements for long unattended 

life and severe restrictions on power, weight, and volume. Reliability 
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is the most severe constraint which affects the computer architec- 
ture in several ways. In most cases, only proven (5 to 10-year old) 
technology can be used to minimize the chance of unexpected failure 
modes. Parts are extensively tested and screened for reliability, 
driving their cost to 10 or more times those in commercial market 
place. Redundant processors, memories, and input/output (I/O) cir- 
cuits double or triple the amount of hardware that is used. Thus, 
reliability requirements induce the majority of costs for onboard 
computing. 

The JPL program (a major contributor to NEEDS technology) in fault 
tolerant computing has had two major parts. The first was the de- 
velopment of a fault tolerant uniprocessor designated the JPL self- 
testing and repairing (STAR) computer (1961 to 1972). It was aimed 
at the flight technology of the early 1970' s (e.g., bipolar SSI/MSI 
and plated-wine memory). A breadboard STAR computer was constructed 
and tested in 1970 to 1972. 

The second part of this program was started in 1973 to develop fault- 
tolerant distributed processing systems, and is a continuing program. 
The development of low-power high density microprocessor technology 
has allowed the replacement of an expensive shared computing resource 
with small computers placed where they are needed in a number of sub- 
systems and science experiments. 

The problems of complexity, software reliability and hardware fault 
tolerance have been addressed, and a breadboard distributed computing 
system has been constructed and used to emulate a number of spacecraft 
computing functions. 

Today both the knowledge and the technology exist to build highly 
reliable computers at only small penalties of size, weight, and cost. 
The reliability of these computers is achieved through a redundant 
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or fault-tolerant architecture. VLSI technology provides the capa- 
bility of putting large amounts of circuitry in small and inexpensive 
packages. By using a standby redundant architecture in which un- 
powered elements of the computer are spare, computer system relia- 
bility can be improved in increments by adding spares. The long 
term potential result is systems which are sufficiently reliable, 
that they do not require technician or logistic support for the 
life of their mission. In the shorter term, systems can be built 
which utilize a highly reliable core computer which can significantly 
aid in the diagnosis and maintenance of the entire system. 

Fault tolerance is the ability to continue correct operation in the 
presence of failures. Self-checking circuits are capable of detect- 
ing their own malfunctions. Study has resulted in the definition of 
four VLSI circuits which allow the construction of a single or a 
distributed fault-tolerant computer system. The four building-block 
circuits are: (1) an error detecting (and correcting) Memory Inter- 

face, (2) a programmable Bus Interface, (3) a core Building Block, 
and (4) an I/O Building Block. These circuits interface with two 
commercial microprocessors and commercial memory to form a Self- 
Checking Computer Module (SCCM). 

In short, the important attributes of this building-block approach 
to fault- tolerant computing are: 

(1) Using the four VLSI building blocks, Self-Checking Computer 
Modules can be constructed from a variety of commercial micro- 
processors and memories. 

(2) The self-checking property of the SCCM allows these machines 
to instantly detect and signal internal faults, thus, allowing 
straightforward implementation of automated recovery by backup 
spares. 


2-24 



(3) Using the SCCM's as building blocks allows the system ” 
designer to choose from a wide variety of system architectures 
He is allowed full flexibility in the tradeoff between redun- 
dancy and performance in adding or deleting computers in the 
system. 

A typical Self-Checking Computer Module is shown in figure 2-9. 

It provides a computer building block with a great deal of comput- 
ing power. A 16-bit processor with instruction cycles in the 
range of 1 to 2 microseconds would be provided along with 32 thou- 
sand words of memory. 
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Bl - BUS INTERFACE BUILDING BLOCK 
qORE • CORE BUILDING BLOCK 
I/O - I/O BUILDING BLOCK 
lif _ - MICROFROCESSpR, 

Figure 2-9. A Self-Checking Computer Module 

Typical packaging would be a 50-square inch multilayer board con- 
taining 23 commercial RAM's and two commercial microprocessors. 
The building-block circuits are one Memory Interface (MI), one 
Core circuit (C), three Bus Interfaces (BI), and two I/O devices 
( 10 ). 
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Through the use of LSI, the cost of hardware has dropped to the 
point where a fault- tolerant computer costs much less than a non- 
fault-tolerant computer did only a few years ago. Using LSI cir- 
cuits, the intrinsic reliability of computer systems has improved 
greatly, but not enough to provide fault-free operation.. This is 
achieved by fault-tolerant, i.e. , self-repairing, architectures 
which offer fault-free operation of a year or more with current 
technology. The current cost of fault tolerance is on the order 
of the an extra $10,000 to $20,000 per computer. This is largely 
due to the cost of the additional high reliability parts which are 
many times more expensive than commercial quality devices. Current 
costs may be significantly reduced in two ways: (1) the use of 

self- testing logic should make them much more easily tested, thus 
reducing a large production cost, and (2) using fault tolerance 
Tess component screening is required since an occasional failure 
is automatically corrected. 

VSLI circuit development is not static and by the mi d- 1980 's there 
should be major improvements in this fault-tolerant computer tech- 
nology. For example, we can expect an SCCM to be packaged on one 
or two chips at a cost of less than $1,000. Components can be ex- 
pected to be several times more reliable, producing an equivalent 
increase in the reliable life of the fault- tolerant configurations. 
One can project conservatively that fault-tolerant machines can be 
built in a few years which provide 5 to 10 years of maintenance- 
free operation at less than $1,000 in increased costs. 

f. Additional Efforts . An onboard mass memory study is underway 
at GSFC. The requirements for this device include: 

(1) 10^^ bit capacity memory. 

(2) 20 megabit playback to ground. 

(3) 20 megabit maximum record rate. 
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The candidates for this technology study include: 

(1) Magnetic bubble 

(2) Magnetic disk 

(3) Optical Disk 

(4) Semi-conductor (CCD, MNOS) 

(5) Tape recorder 

The conclusions of this study and future actions proposed are 
summarized below: 

(1) All solid state or high potential options to tape recorder 
involve high risk today. 

(2) Technology survey and development. 

(a) C omplete 1 0^ to 10^ bit survey (1980) 

(b) Initiate MNOS unit evaluation for 10^ -10® bit 
storage (1981) 

(c) Complete 10^® bit survey (1981) 

(d) Initiate development of technology for 10^® bit 
storage (1982) 

(3) Continue magnetic bubble research. 

(4) Expand optical disc research into onboard applications. 

(5) Continue onboard processing research and technology to 
reduce raw data storage by: 

(a) Perform preprocessing (radiometric and geometric) 

(b) Data editing and instrument control (eliminate 
redundant, useless, or unwanted data) 

(c) Provide onboard information extraction. 

The results of a preliminary data storage survey are shown in 
table 2-3. 
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Table 2-3. Data Storage Survey 
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g. Other NASA data storage technology efforts underway include: 


(1) Magnetic bubble device research at LaRC for the IAS 
el ement. 

(2) Optical disk system (for a ground-based archives) re- 
search for the AMM element at MSFC. 

(3) A survey of memory technology at GSFC. 

Once the memory technology study is complete, a recommendation on 
one or two approaches will lead to a contract award for development. 

t 

Associated with these conceptual efforts is a team at GSFC (under 
IAS leadership) studying protocols and architectures of file optics 
data bus implementation. The design goal is a 200 megabit bus data 
rate. A contract will be let soon but no demonstration is envisioned. 
The technology developed will be applied to packet switching. 

Additional developments in spatial data management software and hard- 
ware technology include a study being conducted on video and optical 

12 

disk advancements. Present conclusions imply a capability for a 10 
bits capacity with a much improved interactive feature resulting from 
the optic supported user interface. An immediate application is seen 
for the shuttle missions. A commercial product is available from 
Discovision however, it is an analog version. 

In digital disk technology, a very low cost media (a write once 
method) RCA and Philips are developing versions. 

In a related element, IAS algorithms are being studied for suita- 
bility in developing channel coding technology. 

2. 2. 3. 3 Element Interface . Presently no information is available in 
this element's integration with other demonstration systems. 
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2. 2. 3. 4 Demonstration Activities . Overall demonstration plans have 
been determined and documented. A joint GSFC and JPL demonstration is 
currently scheduled for December 1980 (see figure 2-10). Originally, 
planned as an integrated system demonstration with technological ele- 
ments from both the IAS and ADSC the necessary interfaces with these 
elements will be simulated. Features to be demonstrated at the JPL 
facility test site include: 

a. Packet! zing using real instrument data provided by tape 
recorder. 

b. Packet queuing. 

c. Frame generation. 

This packetized experimental data will have frame header generation and 
be sent over the 56 kbs NASCOM lines to GSFC. 

At GSFC, the demonstration will feature data capture and data staging 
functions. Although not part of the demonstration of December 1980, 
the data path would conceptually be transferred to the DBMS element at 
this point for data reduction, compression, and archival storage. 

2.2.4 DATA BASE MANAGEMENT SYSTEMS 

2. 2. 4.1 Program Objective . This technology element is responsible for 
developing and demonstrating a brassboard model of a data base management 
system with the following features: 

a. Improvement in data access time through the use of high speed 
secondary storage hardware. 

b. Distributive processing utilizing microprocessors programmed 
for data base management functions only. 

c. Simpler user-to-data-base interactions through the use of re- 
lational data base structure software. 



Figure 2-10. MOTS Demonstration Configuration and Capabilities 




2. 2. 4. 2 Technology Activity . The technology being developed within 
this element falls into three distinct areas: (1) GSFC is responsible 

for the development of a relational data base structure; (2) MSFC is 
responsible for the development of hardware including fiber optic re- 
search for high speed secondary storage (AMM) ; and (3) distributed 
processing on advanced microprocessors supporting data base management 
functions. 

The requirements on the data base structure phase include: 

a. Flexibility in both off-line and on-line support of user 
queuing functions. 

b. In addition to being a commercially available product the 
software must be ameneable to modifications required to inter- 
face with AMM hardware and software to be developed at MSFC. 

This includes the DEC VAX 11/780 processor. 

Lastly, the DBMS must support access to user data files without format 
conversion on many storage systems such as tape, disk, or memory. 

Towards these goals a survey of commercial packages was initiated and 
interim results find the number of candidates reduced from an original 
list of 77 to 16, 

The final selection of a DBMS including trade-offs and mods required 
to implement is to be completed. 

A technological test Bed will be conducted (prior to the integrated 
demonstration with elements of MSFC) using as an application the Pilot 
Climate Data Base Management System. It will be used to resolve tech- 
nical problems associated with providing unified data management support 
for multi-parameter, multi-source climate-related data. It will be used 
to investigate interactive capabiTities needed to interface with users 
and producers of climate data. As a pilot system, it will permit the 
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development of DBMS capabilities that can evolve into a broader NASA 
climate DBMS. 

The PCDBMS will provide comprehensive capabilities but initially will 
support a limited quantity of data which will be periodically updated 
and expanded. One aspect of the PCDBMS will be the development and 
on-going maintenance of a catalog, for system users, describing data 
sets and their data products. 

The technology involved in the deve.Topment/use of a fiber optics ele- 
ment is that heretofore they have been used in a point-to-point imple- 
mentation whereas this will be the first application of a fiber optics 
bus in a computer environment. The fiber optics bus is expected to 
operate at 100 megabits. 

The technological requirements for the AMM are stated in the description 
of that element (see paragraph 2,2.5). 

Presently, the MFSC distributed processing concept hardware configuration 
includes the use of a triport memory providing two data paths to the AMM, 
minimizing user access delay time during high rate input of sensor data, 
and allowing for DBMS/AMM exchange (see figure 2-11). 

Planned activity includes the IDBMS selection, the analysis of data sets 
(OSS) and implementation tradeoffs, the definition of DBMS/AMM interface 
protocols and physical connection and the definition of all X.25 param- 
eters and packet header formats for the data staging interface. 

2. 2. 4. 3 Element Interface . A demonstration of AMM integrated with DBMS 
is planned for September 1981 although some of the DBMS support will be 
simulated. 



Figure 2-11. DBMS Hardware Configurati 














2. 2. 4. 4 Demonstration Activities . A demonstration of the following 
capabilities is scehduled for the second quarter of 1982. 

a. Move data at 50 mbs through the system. 

b. AMM integration. 

c. Accept sensor data, archive it, create directives with primary 
and secondary headers and make available to users in a finite period 
of time. 

d. Build a comprehensive directory of all data including ancillary 
and allow users to interact with. 

The demonstration data sets will be selected from both scientific and 
applications areas. In science, DE, ICEE and Weather/ Cl imate data will 
be accepted and primary/secondary headers will be constructed. The Pi's 
will do extraction of DE and ISEE data sets. 

The Weather/Climate data will have been already processed at GSFC (Pat 
Gary) and most information extraction will be accomplished here. 

Also, the DBMS element staging areas will be transmitting to MSEC. This 
demonstration may include image display functions. 

2.2.5 ARCHIVAL MASS MEMORY 

2. 2. 5.1 Program Objective. The development of an optical mass memory 



system modularly expandable to a storage and retrieval capacity of 10 
bits will be undertaken in this technology element. This system is in- 
tended to replace the use of magnetic tape and microfilm used in the 
archival storage facilities of large data base centers. The system 
will feature secure archival storage, lower overall storage cost, simpli- 
fied design and operation, greater reliability, minimization of data 
maintenance requirements, simplified replication and dissemination, 
modular software tailorable to meet needs of multiple users, simplified 
data base management keyed to user needs, compatibility with existing 
systems, and expandable and cost-effective design and implementation. 
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2. 2. 5. 2 Technology Activity . The requirements for an archival mass 
memory device include: 

12 

a. 10 bits on-line storage 

13 

b. 10 bits off-line expandable 

c. Max access time for on-line 15 sec 

d. Max access time for off-line 3 min 

e. Read/record rate-50 mb/sec 

g 

f. Bit error rate 10 

2 

g. Recording density 30 mb/in 

h. Archivabil ity 10 y^r 

i. Unit record replication 

13 

AMM is high capacity 10 photographic film device the only storage 

medium guaranteed to be archival, uses optical digital spots 2.5 microns 

g 

each and 1 fiche 160 x 160 mm each of 10 bits. 

The anticipated development is the ability to read/write on fiche large 
amounts of storage data. 

AMM provides a large storage system through the VAX systems, 2, VAX 1, 
and VAX 2 [see figure 2-11) and a resident VAX in the AMM. The concept 
is to build modular components which can be added on. The AMM interfaces 
through the triport system and can communicate through a shared memory 
system. 

AMM does own file management but DBMS puts headers on, but AMM can operate 
independently of DBMS since a constraint on the VAX is the inability to 
operate at 50 megabits/sec rate. 

Harris is_ developing AMM. They were chosen because Jhey already Jh^^^ 
components in house from other development areas and so AMM presented a 
"system problem" but required no new technology breakthroughs. 
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They had conducted a survey of industry needs which included type, usage 
rate, and data formats for massive storage requirements. This is why 
AMM is on-schedule. 

Because of the aforementioned, the NEEDS program was timely in providing 
an application Cdemonstration) for MSEC technology. 

2. 2. 5. 3 Element Interface . A demonstration of AMM integrated with DBMS 
is planned for September 1981. 

2. 2. 5. 4 Demonstration Activities . A factory test is scheduled by con- 
tractor in June 1981. A demonstration of AMM integrated with DBMS 
CSeptember 1981) will verify the design criteria of the hardware, com- 
patibility of hardware and overall system performance requirements. 

As a minimum, the. tests will include: 

a. Measurement of corrected BER. 

b. Measurement of data file access time, 

c. Measurement of system storage capability. 

d. Measurement of data transfer rates. 

e. Measurement of accuracy of data replication. 

2.2.6 ANCILLARY DATA AND SUPPORT COMPUTING 

2. 2. 6.1 Program Objective . To design, develop, and demonstrate Ancillary 
Data and Support Computing techniques to support the NEEDS program and be 
consistent with NEEDS fundamental concepts. The ancillary data elements 
are to include spacecraft orbit, attitude, and universal time for near- 
Earth and deep space missions. The emphasis is the onboard computation 
of these parameters. The support computing function is to include the 
validation and maintenance of data necessary to support the ancillary data 
module in the spacecraft, and related ground support functions such as the 
generation of other derived ancillary data and the formatting of that data 
into standard data packets for distribution by the MDTS. 


2. 2. 6. 2 Technology Activity . The technology to be developed within 
this element includes improved packing densities in LSI architecture, 
receivers, and advanced microprocessors. Requirements involve the use 
of all plug-in type ROM's so as to reconfigure for different mission 
requirements. This adaptability is necessary because of the large 
spectrum of potential users. 

Another requirement is a highly partitioned system which will allow a 
selection of various RF's with less noise. 

Available in November 1980 are. four prototype versions of a GPS receiver/ 
processor assembly. Two will fly on Landsat-D and two will go to the DOD 
GSFC will study the packing density and miniprocessor technology archi- 
tectures with an emphasis on modularity and adaptability. 

Advancement needed includes development by DOD of improved packing den- 
sity of LSI technology. 

Ground Support Processing for Onboard Ancillary Data , a study conducted 
by ORI for this element sought to: 

a. Define the requirements of forthcoming identifiable missions 
for ancillary data; timing, orbit and attitude data. 

b. Identify the ground processing functions required to support 
the general onboard timing, orbit, and attitude computation opera- 
tion. 

c. Identify alternative concepts for onboard ancillary data compu- 
tation and describe the effects on ground support computing. 

The following is a summary of suggested conclusions: 

a. Attitude history tapes would be eliminated. 


b. Less frequent attitude determinations required. 



c. For semi-aatonomous attitude determination systems (SMM, 
Landsat-D S/C) ground augmentation of OBC computations will be 
retained. 

d. But for fully autonomous systems (with sufficient memory to 
store star catalogs) the ground support task would be one of 
validation only. 

e. Orbit data will not have to be merged on the ground with 
sensor data. 

f. With orbit, attitude, and time computed onboard, ground sup- 
port will no longer have to merge ancillary data with experimenter 
and spacecraft engineering data. 

The future actions of this element will include: 

a. Complete draft of ADSC concepts document by April 30, 1980. 

b. Initiate design of modular GPS unit in spring/ summer of 1980. 

c. Initiate top-level microprocessor design and definition studies 
for onboard attitude computations in April /May of 1980. 

d. Continue coordination of onboard TDRSS orbit determination 
activity with onboard GPS activity, 

e. Continue coordination of timing modular with the network time 
and synchronization activity and the GSFC data systems requirements 
committee, including JPL personnel in coordination activity. 

2. 2. 6, 3 Element Interface . Presently no information is available in 
this elements integration with other demonstration systems due to a lack 
of a concepts document defining data protocols, etc. 
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2. 2. 6. 4 Demonstration Activities . A demonstration will feature a brass- 
board receiver cumulation which will attempt to illustrate key architec- 
tural concepts only. Figures 2-12 and 2-13 show impact of onboard pro- 
cessing on attitude ground support elements. 

2.3 SOFTWARE TECHNOLOGY 

2.3.1 SOFTWARE VERIFICATION AND VALIDATION - LaRC 

As a support effort to ensure highly reliable flight software for ever 
more autonomous spacecraft and instruments, an integrated verification 
and validation system for flight software in the HAL/S language is being 
developed. The system will be based on the most recent research results 
in verification and validation and will select applicable techniques such 
as data flow analysis, symbolic execution, dynamic analysis, and execut- 
able assertions. 

A contract award for this effort will be made in August 1980, with a 
proposed system demonstration about April 1982. 

The MUST system (see figure 2-14) is a conceptual arrangement of compati- 
ble software development tools and methodology designed to reduce devel- 
opmental time and costs, and to enhance the quality and reliability of 
research flight software production. 

The MUST system is being developed by the LaRC and will be hosted ini- 
tially on the CDC 6000/CYBER machines of the LaRC computer couples (under 
the Network Operating System - NOS). The system is intended to be gen- 
erally applicable to NASA flight software development projects and may 
be installed at other NASA centers on other ground-based host computers. 

The V&T system will be applied primarily to flight code written in the 
HAL/S language. The HAL/S language has been selected and established as 
an NASA standard language for flight code programming. 
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Figure 2-12. Generalized Attitude Ground Support Elements W/0 On-Board 
Processing 
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Figure 2-12. Generalized Attitude Ground Support with On-Board Process! 
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Figure 2-14. MUST System Configuration 















The Verification and Testing (V&T) system will be developed and installed 
on the LaRC computer complex as a set of invokable flight software analy- 
sis tools within the MUST system environment. The fundamental purpose of 
the V&T system tools is to provide the flight code developer (user) with 
analysis capabilities and assistance in the conduct of code verification 
and testing. 

2.3.2 SYNTHETIC APERTURE RADAR PROCESSOR 

An advanced SAR processor is being developed to provide more efficient 
processing of space-acquired SAR data. Currently available digital 
processors required approximately 10 hours to process 100 x 100 km 
Seasat-A SAR image which was acquired in a few minutes. A ground-based 
SAR processor is to be developed which, by FY85, will increase the pro- 
cessing speed by 2000 times over currently used methods of SAR process- 

i-ng-i — T-he-pl-ans-far-th4 s-aet4vi ty' -i ncTude-the-i rrft-i at4on-o f a competi - 

tive industry design contracts in FY80, the start of an industry design 
ground-based SAR processor in FY81 with hardware and software delivery 
in 1985. The preliminary performance parameters are: 

a. 700 km altitude 

b. 75° incident angle 

c. 50 km swath width 

d. 15 m resolution 

e. 2 looks (range and azimuth) 

f. L and X band with two polarizations each 

A ground-based design will be demonstrated in 1985. 

A long range goal is the development of a second generation system by the 
early 1990 's capable of use onboard a spacecraft for direct processing of 
space-acquired SAR imagery. 


2.3.3 - COMMAND/ CONTROL 

2 

A new GSFC team called C for Command and Control headed by B. Bartlette 
is studying systems packet technology for command handling concepts and 
procedures for system analysis of TORS command environment in the future. 

2.3.4 CHANNEL CODING 

A study is being conducted by M. Miller of GSFC in channel coding for the 
TDRS with emphasis on the evaluation of present and future TORS links. 

2.4 SUMMARY 

Although it can be projected that NASA's advanced onboard processor tech- 
nology activities supported by the dynamic R&D of the electronics industry 
will enable complex pjiboard computing functions such as multi spectral 
classification, SAR processing and information extraction by the 1990's, 
an examination of the foregoing material on the various NEEDS Phase 2 
elements yields an immediate breakdown of the efforts into two distinct 
classes. The programs under IAS, ADSC, MDTS, and DBMS are somewhat imma- 
ture and definite technological advances seem to be distant. On the other 
hand, the MPP and AMM elements seem to be well advanced in concept, goal, 
and potential for well-defined new technology. This is due in part to the 
advanced stages of these elements and to the fact that their respective 
interfaces to the other elements Cintegration) are well-defined. They can 
be developed rather independently of the others. Both are well into con- 
tractual development phases. 

Table 2-4 depicts the anticipated improvements resulting from NEEDS ele- 
ments technologies. The IAS effort seems to be in a reevaluation phase 
at GSFC, the ADSC element lacks a concepts document at this time, the 
MDTS concepts document is incomplete and unavailable but it should ne 
noted that JPL is well into the technology required for demonstration of 
this element. 
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Table 2-4. Anticipated Improvements Resulting from NEEDS Technology 

































Overall, there exists a lot of contracts to be let and a lot of concepts 
which have to find technology in order to be implemented for NEEDS Phase 
2 goals. 
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SECTION 3. OSTA/NEEDS INTERFACE ASSESSMENT 




SECTION 3. OSTA/NEEDS INTERFACE ASSESSMENT 


3.1 INTRODUCTION 

After careful consideration of the results of Phase I of this study and 
an investigation of the potential thrusts of ongoing technological 
developments an identification of two major impacts to the NEEDS concepts 
and technology can be made. The first results from instrument require- 
ments which will satisfy the need to detect data and transfer it into 
a useable form. The second is a more integrated or disciplined need 
which will disseminate user required data. 

A discussion of the impacts of instruments and disciplines- to the NEEDS 
evolution follows. A chart sumnarizes the critical technological impacts 
(refer to table 3-1). 

3.2 INSTRUMENTS 


The major drivers for the instrument impact on NEEDS results from the 
functional capabilities being pursued to process, store and deliver data. 
Representative generic classes of instruments have been chosen for 
consideration because of. their unique and sufficient impact on developing 
NEEDS technologies. They represent sufficient conditions in the sense 
that their impact to the NEEDS concept is critical and if not met will 
cause significant over-all system failure in the delivery of space 
acquired data. They present a single point failure potential. 

Likewise they are unique in that they represent the first of the new 
technology of the future. 
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Table 3-1. Technological Impacts and NEEDS 
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The following instruments represent impacts to the NEEDS concepts and 
developing technologies: 

a. SAR 

b. LIDAR 

c. MMLA 

3.2.1 SAR 

Synthetic Aperture Radar (SAR) is an active microwave sensor sometimes 
called coherent radar or sidelooking radar. As with conventional radars, 
the area of interest is flooded with microwave radiation of controllable 
characteristics and the return reflections are operated upon. The 
synthetic-aperture radar, a unique type of active sensor, differs from a 
conventional "real" aperture radar primarily in the method for achieving 
azimuthal resolution along the track. The real -aperture radar uses an 
antenna of maximum practical length to produce a narrow beam. The 
synthetic-aperture device employs a relatively small sidelooking antenna 
that transmits a moderately broad beam. Due to the relative motion of 
the target with respect to the antenna, the target is synthetically 
resolved at a substantially narrower beam in the azimuth, as if it had 
been observed with a much longer antenna. 

The spatial resolution, which in a focused synthetic-aperture radar is 
independent of the target's range, is of course, a very critical parameter 
for all types of active sensors. Another important parameter, which 
sometimes has to be traded off against resolution, is the signal-to-noise 
ratio after averaging a large number of return pulses. A radar's signal- 
to-noise ratio is the counterpart of temperature resolution in passive 
sensors. Improving that radio requires averaging a number of independent 
signal returns from the same resolution cell. 

For the synthetic-aperture radar, the averaging requirement reduces the 
spatial resolution, because the available integration time is divided by 
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multiple looks over the same resolution cell. For example, the best 
achievable azimuth resolution of Seasat's synthetic-aperture radar was 
6 m. But after four looks were averaged to improve the speckle effect, 
the resulting resolution was 24 m. 

Synthetic Aperture Radar systems proposed for the 1990 's are currently 
under investigation by a number of NASA centers, contractors, and a few 
of the larger universities throughout the U.S. The primary focus is on 
data processing because of the impact on .present data systems, i.e., 
Seasat-A SAR, and more importantly the effect on future systems by the 
volume of imagery to be generated by free-flyers (automated payloads) 
and Spacelab in the future. 

Synthetic Aperture Radar systems perceived for free-flyer applications 
in the 1990's will include a digital processing capability. Free-flyers 
will be particularly useful in monitoring the dynamic features of our 
environment, such as sea state, soil moisture, biological growth, etc. 
These applications rely on timeliness of the image product so that near 
real-time processing and subsequent transmission to an appropriate site 
represents a highly desirable system capability. 

Although the SAR data rates are nominal (£ 250 MBPS) the major impact is 
on ground processing. L. Holcomb (NASA Headquarters) has two studies 
underway to investigate SAR processing technologies. The requirement 
exists for real-time SAR processing in the near future. 

Optical processing has been used in many previous SAR systems. This is 
not performed in real-time and therefore requires the radar data to be 
stored on film for subsequent processing. When the amount of data 
collected by the SAR is not too large digital processing in real-time 
may be more convenient than optical processing. 

Digital processing can be performed on board with the processed data 
relayed to ground, or the radar output can be relayed directly to ground 
processing centers. 


The use of parallel processors in reducing SAR data is being actively 
studied by several groups. The results of a MITRE study on this area 
are presented in section 2.2.2. 

A cursory examination of the SIR-A radar and the intended applications 
indicates that it will have a rather limited capability. Further study 
and experience with the data should indicate whether a SIR-A type radar 
should be considered for "routine" sensing as a "free-flyer" for the 
continuing acquisition of data or whether it can only be considered as 
the first step in the development of a more sophisticated radar with 
enhanced capabilities. 

The objective of the Spaceborne Imaging Radar-B (SIR-B) experiment is to 
develop the technical base and evaluate the application potential of 
spaceborne radar imagers for Earth resources observations. Present imagers 
(on LANDSAT) cover a very small arange of the electromagnetic spectrum 
(visible and near-infrared). The extension of the spectral coverage to 
the microwave region would provide additional information on the properties 
of the Earth's surface. This information would help in the monitoring, 
managing, and evaluating of Earth resources. The SIR-B experiment is an 
applications proof-of-concept experiment for the imaging radar, which is 
a natural candidate for the payload of the Global Resources Monitoring 
System (GRMS). 

The SIR-B is a flexible sensor that allows changes in the observation 
parameters. It consists of a dual frequency (C- and X-band) synthetic 
aperture radar. The X-band will have direct and cross-polarized channels. 
The incidence angle is selectable anywhere between 15° (from straight 
down) and about 65°. The combination of the SIR-A and SIR-B experiment 
would provide sufficient information to define the parameters of the 
required operational spaceborne radar sensor. 

The data from a typical 7-day mission are returned to the ground and 
played back, through a tape recorder similar to that in the spacecraft. 
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into a ground digital processor. The processor provides both range 
and azimuth correlation and also performs a first-order geometric 
correction. Outputs from the correlator are produced in film and in 
high-density digital tape (HDDT). The film is probably most useful as 
an indicator of data regions deserving more quantitative analysis. The 
HDDT's, on the other hand, contain the full complement of radiometric 
and geometric correction information for use with subsequent user 
algorithms. 

The final step in data usage and application rests with the users. The 
special processing, including specific algorithm development, is best 
per'formed as a set of more or less independent developments. It is 
anticipated, for example, that the requirements of geological users 
regarding radiometric and geometric accuracy might differ significantly 
from those of agricultural users. The "standards" product supplied to 
the users is, therefore, as application-independent as possible. 

The development of processing algorithms should parallel ground and 
onboard SAR data-processor-hardware development. Electronic processing 
of SAR data into images appears superior to the optical processing used 
to date. The state of the art for ground-based electronic processing 
is well advanced. Hence, development of a system for SIR-B can be 
started at an appropriate time to make it available for use with the 
Shuttle tape- recorded .data for that, system, .. 

Radar systems with modest resolution can use on-board processing of signal 
into images. The telemetry bandwidth for the processed image will be 
significantly less than that required for the signal itself. However, 
for systems that achieve the finest possible resolution and have multiple 
channels, on-board data processing is complicated and needs development. 
Consequently, the testing of these sytems on the Shuttle and use of them 
on early free-flying spacecraft should be an integral part of the micro- 
wave remote sensing for Earth observation. 



3.2.2 LIDAR 


First conceived on in 1963, "lidar" stands for light detection and 
ranging. It can be throught of as laser radar using light in place of 
radio waves. Radiation from a laser is pulsed into the atmosphere. 

As the light passes through various atmospheric regions, particles, 
liquid droplets and gaseous molecules scatter or absorb it in different 
ways . 

Some portion of the scattered or emitted light returns to its point of 
origin, where a telescope-like receiver channels it to a photodetector. 
The photodector produces an electrical signal proportional to the optical 
radiation received" by the telescopeT The length of time between 
transmission and reception indicates from what distance the light was 
scattered, and the intensity of the electrical signal indicates the 
conce ntr ation of the particles or molecules being monitored. 

In practice, these time and intensity readings require more elaborate 
processing to fully describe the atmospheric conditions. When this is 
done, however, they can be used to establish profiels of various atmos- 
pheric components. For instance, if laser light tuned to scatter from 
aerosols is scanned across a given portion of the atmosphere, a cloud 
cover profile may be constructed by lidar. Or, if tuned to an absorption 
frequency of a certain pollutant, a ladar can map out the presence and 
intensity of that polutant over a given area. 

Lidar has been used for a number of years in a variety of configurations. 
Profiles can be produced by scanning radially from a fixed location or 
by mounting a unit on a moving vehicle, such as a van or airplane. But 
not existing technique fully realizes the global potential of lidar, 
which could cover broader geographic areas and more regions of the 
atmosphere. 
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As backscatter data accumulates during a Shuttle Lidar run, it will be 
digitized and stored on tapes. When the shuttle comes into range of a 
tracking and data relay satellite (TORS), data will be "dumped" at high 
rates to the satellite, which will then transmit it to a ground station. 
Goddard Space Flight Center will process the digital data and will make 
it available to principal investigators in the program, who will do 
their own interpretation and analysis. 

An interesting arrangement of lidar and MSS (Multispectra Scanner) can 
be envisioned on one platform which would potentially enhance resolution 
through more efficient error checking. 

3.2.3 MMLA 

The Multi spectral Multilinear Array (MMLA) will utilize the multilinear 
array technology with multiarrays covering the spectral range of 0.4 to 
2.5 ym at bandwidths as small as 20 nm. The MMLA will eventually replace 
the MSS and TM. The high data rate of the MMLA and the processing required 
to use it will have a major impact on NEEDS. Adaptive bandwidth, 
autonomous data packing, ground processing and data distribution/integration 
techniques will be needed. Additionally, the area of user needs (by 
discipline) will have to be examined and even perhaps some priority 
established on the selection and use of algorithm processes. 

3.3 DISCIPLINE SYSTEMS 

Several discipline or integrated system thrusts on evolving NEEDS technolo- 
gies can be identified. They fall into several of the following areas: 

a. Data systems 

b. Networking 

c. Distributed cataloging systems 

Components of each are discussed and a chart (table 3-1) summarizes their 
impacts. 
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3.3.1 DATA SYSTEMS CONCEPTS 


Two components of this are user directed targeting in a near real-time 
mode and a multi disciplined instrument payloads. These concepts are not 
new but with the proliferation of new radar imagery and microprocessor 
technologies it seems almost inevitable that some form of these will make 
themselves felt on developing NEEDS technologies. Direct unloading of 
experimented data to the user is a strong contender for aleviating the 
bottleneck at the ground processing phase of NASA's system. Furthermore, 
the use of many different types of instruments on one platform will 
present real problems in data autonomy procedures. 

The following is a brief presentation of these data system concepts 
which will have an important impact to NEEDS developments. 

3.3. 1.1 User Control (Near Real-Time) . This concept has been studied 

-f 0 r-n-early~2t)' years-at-NAS At and-wa i'tecHf or-by-many-'S pace-re search o r i en ted 
groups. With communications and networking technologies as advanced 
as today there is strong compelling justification for near real-time user 
control of experimental equipment in space. Although a "joy sticking" 
capability may be somewhere in the future a virtual -type "by target" 
selection is possible and safe now. The major impact will be in ground 
software capabilities. Command and verification protocols, massive 
distribution data dump capabilities, both transmission and processing, 
archival storage and multiuser data base management technologies will 
have to be developed. 

3. 3. 1.2 BUSS Packing Concept . This many disciplined mission concept 
would allow diverse instruments requiring a common orbit to be flown 
together. The impact of a many to many instrument to user mapping would 
impact the MDTS element most. Again, a virtual target - virtual user 
concept and technology will have to be developed. Of an equally important 
positive impact is the TDAS. With acquisition possible, user routing 
protocols can be developed so as to allow a broadcast capability. 
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3.3.2 NETWORKS 


Although there are a few valued-added networks in operation including 
Telemet, Tymnet, Datapac, Transpac, Saponent, NON, NTT-DDX and perhaps 
at least half a dozen more, the reality is that the average user has not 
much benefited from existing advanced networks unless he happened to be 
tied to Dataroute or DOS. 

The concepts of technology have changed. Packet switching and circuit 
switching have come to look more alike. Packet switching has largely 
dispensed with the concept of self-routing datagrams for the moment, 
adopting instead a circuit switching method of setting up a fixed link 
or virtual circuit between sender and receiver for the duration of a call. 

Internetwork, connections have also been made possible in the last 10 
years, and made to work. Telenet and Tymet both link to Datapac, for 
instance, and Telenet links to Hawaii 'sDasnet IT interisland network. 

In the area of network management we can expect a strong trend toward 
decentralized control of switching and value-added functions but central- 
ized control of network management functions. 

More intelligent, circuit switching will gain in applicability and may 
well take precedence over pack switching for general purpose networks by 
the end of the decade. The support X.20 and X.21 standards by computer 
manufacturers will be a major factor in causing this to happen. 

The fact that it is not known how. the protocol translation and other 
problems are to be solved in future networks should not be an excuse for 
a "wait and see" attitude. 

The single most important fact that has been learned over the last 10 
years is that the only low risk approach to networking is one that 
separates some of the key network functions into clearly distinct network 
entities. The most important separation must be between the "network 
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transport function" (the fundamental transmission, switching, and network 
management functions which all networks must provide) and "value added 
functions" (such as protocol conversion, message storage, formatting, 
and what is now called "communication processing"). 

3.3.3. 1 Data Distribution Network . This system (shown in figure 3-1) 
will function as a switch between 6STDN/TDRSS communications link and 
users, space centers and research centers. Its design will facilitate 
the S/C BUSS packing concept discussed above and augment through concep- 
tual integration with the MDTS element of NEEDS. 

3. 3. 3. 2 Distributed Catalogue Concept . Essential for the future require- 
ments of data base management and independent of any data systems concept 
is a cataloging scheme. As depicted in figure 3-2 a central data process- 
ing facility (unseen by users) supplies data to data distribution network 
which controls the dissemination o f re qu ested dat a thro ugh a data base 
management structure. This concept allows disciplined cataloging and 
archiving functions to occur .transparently and thereby broaden the 
potential spectrum of users. 

3. 3. 3. 3 TDAS Distribution . This data system concept (figure 3-3) 
utilizes the TDAS to broadcast space data directly to the user. 

Primary advantage here is that user unique data handling/processing 
functions do not broaden processing facilities and that users establish 
their own catalogue protocols. 
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Figure 3-1. Data Distribution Network 
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Figure 3-2. Distributed Catalogue System 
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SECTION 4. POTENTIAL OSTA DEMONSTRATIONS AND PILOTS 


This section contains an outline of several pilot studies or demon- 
strating though to be of extreme relevance to the concepts and future 
goals of NEEDS. The first three are an obvious tie between the OSTA 
technology thrusts upon NEEDS while the last would provide an assess- 
ment tool -for measuring, iNEEDSc.effectiveness now and planned capabilities 
for the future. 

4.1 SOFTWARE ALGORITHM REDUCTION 

This study would identify commonly used software algorithms, perform 
some analysis and attempt to reduce the amount of time required to 
execute them. A demorrstration of several critical processing functions 
(SAR data processing) would follow. 

4.2 CATALOGUING MODEL 

This study/demonstration would develop a model of a small scale data 
distribution system utilizing DBMS concepts and include at least 
two levels of user protocol (access) across several disciplines. 

Taped data would suffice as input. Various cataloguing concepts 
could be demonstrated. 

4.3 USER NEEDS 


This pilot would establish guidelines and techniques required to 
assess the data system needs of the various disciplines. In addition 
to data type, frequency, and processing requirements potential data 
integration technologies would be identified. 
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4.4 NEEDS ASSESSMENT 


This pilot study and demonstration would develop parameters for a 
S/W model of NEEDS through the year 2000. Simulation would be devel- 
oped on data storage, data processing and data distribution capabil- 
ities over the next 20 years and include as inputs the impacts of 
instrument technology and disciplines as identified and forthcoming. 
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